Skip to content

Conversation

@williamjhyland
Copy link
Contributor

adds an optional cache_image configuration flag to the Motion Detector vision service. When enabled, the service performs temporal differencing against a cached previous grayscale frame, so each GetDetections / GetClassifications call only captures one image instead of two.

Some cameras / pipelines are sensitive to multiple rapid captures per RPC call (latency, bandwidth, or frame timing issues). Caching the previous frame preserves the same motion-detection algorithm across calls rather than within a single call.

  • cache_image=false (default): existing behavior — capture two frames per call and compare.
  • cache_image=true: capture one frame per call and compare against the last cached frame. On the first call after startup or reconfigure, there is no cached frame yet, so the service caches the frame and returns an empty result ([]).

Copy link
Contributor

@Rob1in Rob1in left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I like this option.
A question and note:
Question: is the issue here that the time between the two images is inconsistent, or that the interval is sometimes too short causing get_image(s) being called too quickly?
If stability is the issue: in this PR, the client of the vision service (event manager?) is responsible for maintaining a stable time interval between two frames for motion detection. But that still might not be that stable.
What about adding an asyncio.sleep() between two images (with a config attribute time_between_frames)? I like the idea of caching last_grey—maybe we could also cache a timestamp to detect inconsistent timing between images, if that’s the real issue.

@williamjhyland
Copy link
Contributor Author

The main issue is that time delays don’t guarantee unique frames with RTSP. Even if you add a sleep, two get_image(s) calls can still return the same decoded frame because of buffering and codec behavior. So a delay helps sometimes, but it’s not reliable.

Since I actually need guaranteed unique frames, that has to happen at the camera layer (block until a new frame or an I-frame). The cache_image option just avoids multiple rapid captures per RPC and compares frames across calls instead of within a single call, without relying on timing assumptions.

@williamjhyland
Copy link
Contributor Author

CI is green now; merging. Appreciate the feedback.

@williamjhyland williamjhyland merged commit e75bc8f into main Jan 5, 2026
1 check passed
williamjhyland added a commit that referenced this pull request Jan 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants